The present invention is related to a computer system which manages the use of video devices by an application program such as video editing system.
Developments in computer technology have resulted in a proliferation of devices capable of processing motion video on a computer. It is generally desirable to provide a form of application programming interface (API) that abstracts low level details of the functions of video processing normally performed by such hardware devices from application programs which are used to develop motion video programs. Ideally, such an API should be both platform independent and device independent so that devices for many machines and platforms all implement the same API, which allows various applications to remain, albeit theoretically, unchanged for different platforms.
One form of video device manager providing such functionality is the xe2x80x9cVDMxe2x80x9d system from Avid Technology, Inc. of Tewksbury, Mass. Another kind of device manager is the ActiveMovie device manager from Microsoft Corporation, which has been extended by Matrox Corporation. Both implementations provide a form of virtual device for the variety of kinds of video processing devices which are used by application programs.
There are several problems to be solved by such device managers. One of these problems is that there may be separate virtual devices for performing compression, decompression, special effects or other processing, which generally implies that data produced by one device is copied to another virtual device in order for it to be used. However, video data copies require large amount of bandwidth and processing. It is desirable to eliminate any unnecessary copies between virtual devices. In addition, some activities to be performed by an application may require sharing of resources, such as a particular physical device. Such resource sharing should be provided in a straightforward yet robust manner.
Sharing of resources of a device by an application is provided by a video device manager which defines contexts which are collections of logical entities used to produce a video composition that are applied to a single collection of physical entities. One of the logical entities may be an input buffer or first-in first-out memory (FIFO). Another may be an output buffer or FIFO. Other logical entities may be defined for compressors, decompressors, video encoders and decoders, mixers and filters. A context is defined for each collection of logical devices that are connected to form what is called a graph. This collection is associated with a collection of connected physical resources.
For example, a graph may be used to define a blend of two compressed video streams using a first channel, defined by an input FIFO, a decompressor and an output FIFO, a second channel, defined by an input FIFO, decompressor and output FIFO, and a blender having two input FIFOs, a mixer and an output FIFO. If two physical decompressors are available then one graph, i.e. one context, is defined. With some physical devices, however, the decompressor used in the first channel may need to be the same chip used in the second channel. In order for the two virtual decompressor devices to share the same physical decompressor device, two contexts are used defining two separate graphs. In order to minimize data copying, input FIFOs are provided with a method for adopting memory locations from other virtual devices, particularly output FIFOs.
Each virtual device may be defined as a state machine. At any given time, a device will be in one of a set of states, such as idle, ready, armed, running and stopped. Only one virtual device per actual physical device may be active at a given time. This constraint is enforced by the use of contexts. When a particular virtual device leaves the idle state, all physical resources required for its use are allocated and locked to this device. By causing the state transitions applied to a device to be applied to all devices it connects to, i.e., all devices in its context, physical devices are shared among different contexts. Upon returning to the idle state, the physical resources are made available for use by other devices.
To implement buffer adoption, the input FIFO object has associated acceptable memory locations. An application may offer to the input FIFO memory locations for adoption where the memory locations are used by another virtual device such as an output FIFO. The input FIFO adoption method simply compares the offered memory locations with those that are considered acceptable. If these memory locations are acceptable, the input FIFO uses them and has a behavior as if a copy had occurred. If the memory locations are not acceptable, a physical copy operation is actually performed.
Accordingly, one aspect of the present invention is a video device manager for managing access to physical video processing devices on a computer by an application program executed on the computer. The video device manager defines a context for each collection of virtual devices that are applied to a collection of physical video processing devices. For an application program, the video device manager defines one or more virtual devices for allowing the application program to access one of the physical video processing devices, wherein each virtual device is defined as a state machine having an idle state and one or more active states. The video device manager ensures that only one context is currently active by causing state transitions applied to one device to be applied to all devices in its context.
Another aspect of the present invention is a video device manager for managing access to physical video processing devices on a computer by an application program executed on the computer. The video device manager defines, for an application program, one or more virtual devices for allowing the application program to access one of the physical video processing devices, wherein each virtual device has a corresponding set of associated memory locations. A virtual device can receive an indication of a memory location from other devices or an application program. The received memory location is compared with the memory locations associated with the virtual device. The data stored in the received memory location is used from the received memory location when the memory location is accessible by the physical video processing device associated with the virtual device. Otherwise, data is copied from the received memory location to the memory locations associated with the virtual device when the memory location is not accessible by the physical video processing device associated with the virtual device.
In one embodiment of the present invention, the video device manager ensures that only one virtual device is active in each context by allocating and locking the corresponding physical video processing device to the virtual device, when one of the virtual devices transitions from the idle state to an active state. When one of the virtual devices transitions to the idle state, the corresponding physical video processing device is deallocated and unlocked.